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1 SYSTEM AND METHOD FOR ENSURING CLIENT ACCESS TO 

2 MESSAGES FROM A SERVER 

3 

4 BACKGROUND OF THE INVENTION 

5 Field of the Invention 

6 The present invention relates to client-server application network 

7 communications. More specifically, the invention relates to managing client-server 

8 communications such that a client has access to all messages from a server. 

.«* 9 

•it 

n|10 Relevant Technology 

3 

4^1 Programmed computers are increasing modern day society's ability to do more 

C±2 work in less time and at less expense. The programs which execute on these computers 

" £ 

CP cover a vast range of subjects and industries. These programs vary in their amount of 

^14 utilization of computer hardware resources. In the end, it is the output of the computer 

£[15 such as, a report, a display, a printed document, and the like which provides the utility 

1 6 found in programmed computers. 

17 Programs for computers may be a single program executing on one computer or a 

18 plurality of program modules distributed across a plurality of individual computers. 

19 Division of a single program into modules may be done for several reasons such as to 

20 protect ownership of a particular module, to save computer resources, or to broadly 

21 increase user access to specific program modules. 
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1 Division of a single program into program modules requires there be some form 

2 of communication rules or relationships between the program modules and hardware to 

3 transmit the communications. The relationships available are varied and often model the 

4 relationships amongst human beings. Examples of models include peer to peer, 

5 master/slave, and client/server. In each model, one program module takes on one role 

6 and a second program takes on the other role. 

7 The hardware needed to transmit inter-program module communications is 

8 standard computer networking hardware which utilizes standard network protocols, e.g., 

=i 9 ISO/OSI, IPX, SNA, OTMA, APPC, TCP/IP, to pass messages from one program module 

? 

;i 
: | s 

1^10 to the other. In addition, each computer on the network needs a network card capable of 

Sh 1 communicating across the network medium. The network medium may be Ethernet, 
^ ■ 

if ;12 token-ring, twisted pair, infrared, radio waves, other wireless mediums and the like. The 

r J13 network may be a local area network LAN, wide area network WAN, or global network 
such as the Internet. 

f|fl5 Inter-program module messages contain two kinds of data, control data and 

16 message data. Depending on the network protocol, there may be one or more layers of 

17 control data. The control data instructs the network hardware how and where to transmit 

18 the message. The message data is the information the sending computer intended to 

19 transmit. Some protocols, such as Open Transaction Message Access ("OTMA"), 

20 provide a portion of the control data which either program module may use to identify 

21 messages. 



3 



1 Of the models for inter-program module relationships, the client/server model is 

2 most prevalent. Client-Server programs are common in most every aspect of 

3 government, business, and commerce today. The development of the Internet has 

4 magnified the importance, growth and the reliance on the client/server model. 

5 A client/server program consists of a client program module, referred to 

6 hereinafter as a client, assuming the role of a client. The client communicates with a 

7 server program module, referred to hereinafter as a server, assuming the role of a server. 

8 A client, as in real life, requests certain services of the server. A server, again as in real 
^ 9 life such as a butler, performs the services requested by the client. In a client/server 
qjIO model, generally the server executes on one computer while the client executes on a 

•si 

; 3 ft 1 remote computer which is connected to the server by a network. While this is not 

:"jl2 necessary, executing the client and the server on the same computer limits the advantages 

C&3 gained by doing otherwise. In order for most advantages of a client/server model to be 
gained, the time required for a server to meet the client request must be short. A client 

--s ~ 

C$5 request which monopolizes the server and its resources moves from a client/server model 

16 to a master/slave model. 

17 The client/server model has distinct advantages. First, a single server may 

18 service multiple clients almost simultaneously. Second, the server may act as a central 

19 repository for data files, database records, web pages, email data, and the like. 

20 Additionally, the server may execute on a computer which has many more computing 

21 resources such as disk space, memory, and computing speed than the computer on which 

22 the client executes. Centralizing the computing resources allows the server to execute 



4 



complex or time consuming calculations on a client's behalf. A single client may not 
need the extra computing resources at any given time but may need the resources at a 
later point during a given time interval. Thus, centralizing the resources and allowing 
multiple clients access to them by way of a server maximizes the use of these resources. 

An example of a server which provides primarily database records to clients is a 
database management system. An example of a database management system is the 
Information Management System (IMS TM ) available from IBM Corp., Armonk, New 
York. The IMS system is used to serve records from a vast number of databases in 
operation today. The IMS system[s] allows access by clients to one or more databases in 
order for users to retrieve and modify the data maintained on the database. The majority 
of client access involves transactional operations. 

A client/server model offers advantages in the design and programming of clients 
as well. In the design of the client and the server the software engineer may decide how 
much functionality to place in the client versus the server. Generally, functionality which 
maximizes computing resources is placed in the server. This functionality is often 
database records and their management or complex computing algorithms. This leaves 
primarily output and server request functionality for the client. Output functionality 
includes displays, reports or other human intelligible computer outputs. Clients with little 
more than output functionality are called thin clients. Thin clients require less computing 
resources on the remote computer. This allows the thin client to execute on a smaller, 
more compact computing device such as a Palm Pilot® or internet enabled mobile phone. 
A thin client also allows the client to be generalized such that the client may execute as a 



plug-in within a client driver program, such as Netscape® or Microsoft Internet 
Explorer®. Using thin clients also allows the program designer to protect proprietary 
algorithms on the server while still providing the service to the clients. 

As mentioned above, the client/server model is most effective with transactional 
operations of short duration. In transactional operations, the client requests a service such 
as the data in a database representing a person's bank account balance. The transaction is 
complete when the server responds to the client with a response message containing the 
balance amount. 

One premise generally relied on when using network protocols is that for each 
client request made of the server there will be a corresponding response sent to the client. 
Even if the response to the client is that the server experienced an error or could not 
service the request, the client expects at least some response message. Similarly the 
server anticipates that the client expects a response and makes arrangements to provide 
one. A protocol for use with the present invention, Open Transaction Message Access 
('OTMA'), also relies on this premise. Response messages are stored in a data structure 
until the server is capable of sending them. Suitable data structures include, queues, 
linked lists, and the like. 

During normal operation, the premise of expected response messages functions 
without any problems. Clients make requests using request messages and the server 
responds using response messages. A completed transaction is a request and its 
corresponding response message. A request and its corresponding response message 



1 comprise as a set of paired messages. The server response message is the pair for the 

2 client request message. 

3 Unfortunately, operations between computers on a network are not completely 

4 free from communication interruptions. Interruptions may take various forms. The client 

5 may make a request and be taken off the network, or off-line, by the user of the client 

6 computer before the server could deliver the response to complete the transaction. 

7 Alternatively, the client may request a server perform a service and send the result to a 

8 second client which is not currently on-line. 

^ % 9 Conventional servers ignore interruption scenarios. The server continues to store 

ijjlO response messages m the queue and continues servicing other clients. Messages which 

1 have become undeliverable because of an interruption are called unpaired messages. The 

C]12 module in the server responsible for delivering the server responses continues to send out 

C)13 responses to clients currently connected to the server. A client is connected when it has 

hi 

'~h4 indicated a desire to communicate with the server and the server has accepted to perform 

|*[15 services for the client. 

16 When communication has been prematurely interrupted, unpaired messages may 

17 accumulate in the server's message response queue. Once the same client re-connects to 

18 the server, the client may send the same request as prior to the interruption or send a 

19 completely different request. However, messages sent from the server to the client are 

20 sent on a first in, first out (FIFO) basis. That is the first message to be stored in the queue 

21 will be sent before subsequent messages stored in the queue. Therefore, the server sends, 
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in response to the client's most recent request, the unpaired response message created in 
response to the last request prior to the interruption. 

Because server response messages are sent on a FIFO basis clientl may request a 
service and ask that the response be sent to client2. At about the same time, client2 has 
made a completely different request. The request from clientl is quickly processed and a 
response to be delivered to client2 is placed in the queue. Then, client2 , s response is 
ready. Conventional server message delivery modules do not distinguish between paired 
and unpaired messages. The message for client2 from client2 is an unpaired message 
which the conventional delivery module simply sends to client2. Because this response is 
not the pair for the request clientl made, an error condition in client2 may result. 

Some clients may have logic to enable the client to recover from an interruption 
and identify the unpaired response message sent by the server and work through the 
problem accordingly. However, most clients do not have such logic. These clients are 
expecting a response to their most recent request and instead are receiving an unpaired 
message. This mis-match, or disconnect in communication may lead to the client 
experiencing an error state or outputting erroneous data. 

Solutions to the response message mismatch generally involve developing clients 
which have logic to manage unpaired messages. This logic increases the size of the client 
executable meaning the clients will require more computing resources. The computing 
resources required lowers the probability that the advantages of thin clients, mentioned 
above, can be recognized. Also, placing this logic in the client may require separate logic 
to handle unpaired messages from each server a client may interact with. 

8 



1 Thus, it would be an advancement in the art to provide a system and method to 

2 manage unpaired messages such that unpaired messages may be utilized by the clients 

3 even after a communications mismatch. It would be a further advancement to provide a 

4 system and method to manage unpaired messages in a single central server location rather 

5 than in each remote client. It would be a further advancement to provide unpaired 

6 message management without increasing the size of the clients. It would be yet another 

7 advancement in the art to provide unpaired message management by using existing server 

8 functionality rather than consuming additional client computer resources. It would be yet 
^ % 9 another advancement in the art to provide a system and method for managing unpaired 
ijjlO messages such that the system and method may be initiated by a client's request. It would 

l {h 1 be yet another advancement in the art to provide a system and method for managing 

m 

Cj2 unpaired messages to recognize the existence of unpaired messages and automatically 

C13 manage these messages for later delivery to the client. It would be yet another 

]= 34 advancement in the art to provide a system and method for managing unpaired messages 

4 s 

: = \ 

r J5 such that the client may request one or more unpaired message be sent to the client. Such 

16 an invention is disclosed and claimed herein. 
17 
18 
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1 SUMMARY OF THE INVENTION 

2 The invention is a system and method for ensuring client access to unpaired 

3 messages from a server. The system includes a server detecting at least one unpaired 

4 message intended for a client and storing this message in a data structure. Subsequent 

5 unpaired messages intended for this client are also stored in the data structure. The 

6 system further includes use of a communications protocol between the client and server. 

7 The protocol allows the server to notify the client when the client has pending unpaired 

8 messages. The client, using the protocol, requests at least one unpaired message stored in 
^9 the data structure. The data structure storing the unpaired messages may be created 

Ci 
'•11 

□|10 statically upon an initialization event within the server or dynamically upon the existence 

1 of the first unpaired message. 
£ il2 The system of the present invention further includes a request module, a response 

Cfl3 generator, an unpaired message module, and a response module. Requests from the client 

^Jl4 for one or more unpaired messages are passed directly from the request module to the 

rj.5 response module. All other requests are passed to the response generator. 

16 The response generator is a general purpose module which is capable of creating 

17 a general or specific response to a client's request. The response generated by the 

18 response generator is analyzed by the impaired message module. The unpaired message 

19 module is configured to distinguish between paired and unpaired messages. The unpaired 

20 message module may be configured to automatically create an unpaired message queue 

21 when a first unpaired message is encountered. The unpaired message module stores 
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1 unpaired messages in the unpaired message queue and stores all other paired messages in 

2 a paired message queue. These queues may be within the response module. 

3 The response module communicates responses from the server to the client. In 

4 normal operation, the response module sends messages in the paired message queue to 

5 the client in the order in which the messages were created. But, if the request module 

6 indicates the client wants one or more unpaired messages, then the response module 

7 sends the corresponding number of unpaired messages from the unpaired message queue 

8 to the client. If there are no messages in the unpaired message queue then the response 
= . 9 module may destroy an existing unpaired message queue related to that client. When the 
JlO first unpaired message is stored in the unpaired message queue, the client sets an unpaired 

Ofc 1 messages waiting indicator in subsequent paired messages to the client to indicate there 

iii 

!;Jl2 are impaired messages for this client in the unpaired message queue. 
£S3 By using an unpaired message module and an impaired message queue within the 

^44 response module many advantages are obtained. First, a client which goes off-line and 

rj5 loses communication with the server, is not confused by unpaired messages which the 

16 client may not have been expecting or configured to handle. This means a server 

17 implementing the present invention may interact with sophisticated and simple clients. 

18 Second, the unpaired message queue may be created dynamically. This saves resources 

19 in the server. And third, the client controls whether impaired messages are sent, the 

20 number that are sent, and whether a properly configured server utilizes the system and 

21 method. 



11 



1 These and other features and advantages of the present invention will become 

2 more fully apparent from the following description and appended claims, or may be 

3 learned by the practice of the invention as set forth hereinafter. 
4 

5 BRIEF DESCRIPTION OF THE DRAWINGS 

6 These and other more detailed and specific objects and features of the present 

7 invention are more fully disclosed in the following specification, with reference to the 

8 accompanying drawings, in which: 

;S= , 9 Figure 1 is a block diagram of a server computer system in communication with a 

jjjio client computer system suitable for implementing one embodiment of the invention; 
CI 

4 J 1 Figure 2 is a flow diagram of one embodiment of a method for communicating 

Li 3 

'I/J2 between a client and a server at connection time such that unpaired messages may be 

Ziit3 delivered to the client; and 

r ^4 Figure 3 is a flow diagram illustrating one embodiment of a method for ensuring 

C^}5 a client has access to messages from a server. 
16 

17 DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 

18 The presently preferred embodiments of the present invention will be best 

19 understood by reference to the drawings, wherein like parts are designated by like 

20 numerals throughout. It will be readily understood that the components of the present 

21 invention, as generally described and illustrated in the figures herein, could be arranged 

22 and designed in a wide variety of different configurations. Thus, the following more 
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1 detailed description of the embodiments of the system, and method of the present 

2 invention, as represented in Figures 1 through 3, is not intended to limit the scope of the 

3 invention, as claimed, but is merely representative of presently preferred embodiments of 

4 the invention. 

5 Figures 1 through 3 are a schematic block diagram and flow chart diagrams 

6 which illustrate in more detail certain embodiments of software modules and steps for 

7 carrying out the present invention. 

8 Figure 1 is a schematic block diagram which illustrates an unpaired message 

^ 9 access system 100 in which a client 102 and a server 104 are connected and configured in 

:J to such a way that unpaired messages may be accessed by the client 102. The clients 102 

|=| 

0ft l are designated client 1 to client n to indicate a plurality of clients 102 which may be 

.5. i. 

:f tl2 connected to the server 104 at any given time. A connection with the server 104 may be a 

£113 conventional network connection by way of a network, a LAN, a WAN or an 

■cr S 

interconnected system of networks, one particular example of which is the Internet and 

r*l5 the World Wide Web supported on the Internet. A connection includes an authorization 

16 by the server 104 to accept requests from a particular client 102 when such requests are 

17 sent through the network. 

18 The clients 102 are computer programs of various configurations operating on 

19 various kinds of computers. Some clients 102 maybe database reporting programs, data 

20 management programs, financial transaction programs, and the like. These clients 102 

21 may vary in their sophistication. Some may be simple database queries. While others 

22 may be complex financial programs which include logic to manage unpaired messages 
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1 resulting from a lost network connection, or communication mismatch with the server 

2 104. 

3 The present invention allows the server 104 to communicate with both simple 

4 and complex clients 1 02. Each client 102 is configured to initiate a connection with the 

5 server 1 04 and conduct transactions with the server 104 once a connection is established. 

6 Transactions are comprised of a service request made of the server 104 by the client 102 

7 and a response sent to the client 102 by the server 104. The response corresponding to a 

8 request is a paired message, as discussed above. An unpaired message is a response 
^ 9 which would be unexpected by the client 102. 

i§lo Requests of the clients 102 are serviced by the server 104. As discussed above, a 

Oil 1 server 104 exists to service requests of clients 102. Of the various services which a 

4" 

^52 server may be programmed to provide, one is database management system ('DBMS'). 

r%3 An example of a database management system within the scope of the present invention 

is IMS, described above. A DBMS is a good example of a server 104 which interacts 

/XlS with its clients 102 generally on a transactional basis. A request from the client 102 is 

16 received by the server 104 and both the server 104 and the client 102 expect a response 

17 will be sent to the client 102 to complete the transaction. 

18 A server 1 04 within the scope of the present invention includes a request module 

19 106, a response generator 108, an unpaired message module 110, and a response module 

20 112. The request module 106 receives client requests 124, performs initial processing of 

21 the requests 124, and routes the requests 124 to the appropriate subsequent module. 

22 Client requests 124 are communicated by way of the network. The client 102 utilizes a 

14 



network communications protocol, such as OTMA, to send a request 124 to the request 
module 106 within the server 104. When the server 104 is a DBMS such as IMS, the 
requests 124 may ask the server 104 to report or modify particular database records. 
Following each request 124, the client 102 waits for a response or acknowledgment that 
the service was successfully performed by the server 104. 

The request module 106 is configured to receive two different kinds of requests 
124. If the request is that unpaired messages 1 16 be sent to the client 102 then the request 
is an unpaired message control request 118 which is sent to the response module 1 12. All 
other requests 124 which the server is programmed to respond to are sent to the response 
generator 108. 

The response generator 108 serves to execute internal functionality to service the 
requests 124. Requests 124 are instructions to perform a service and includes, things like: 
"What is the checking account balance for account #12345678?", or "Please increase the 
checking account balance for account #87654321 to $300.00." Once the service is 
performed, the response generator 108 creates a response appropriate to the particular 
request. Example responses may include: "Checking account balance for account 
#12345678 is $500.00.", or "Balance for checking account #87654321 successfully 
increased to $300.00." Once a response is generated, it is passed to the unpaired message 
module 110. 

The unpaired message module 110 contains logic to determine for each given 
response whether the response is a paired message 1 14 or an unpaired message 116. The 
main question which determines whether the response is a paired or unpaired is: "Has 

15 



1 something happened in communications between this client 102 or another client 102 and 

2 the server 104 such that sending this response as the next response to the client 102 will 

3 result in the client 102 receiving a response which it did not expect?" Various status data 

4 concerning communications between the clients 102 and the server 104 are used to 

5 answer this question. An affirmative answer to the question indicates that the response is 

6 an unpaired message 116 and a negative answer means the response is a paired message 

7 114. 

8 In normal operation, a client may make numerous requests 124 of a server 104. 
Mi 9 Each request 124 results in a corresponding response 126. Requests 124 are not always 
QdO responded to in the same amount of time. Some responses 126 to early requests 124 are 

: = - 

04 1 generated following responses 126 to requests 124 received later in time. The unpaired 

: = S 

J 2 message module 110 also identifies these situations and orders a client's 102 responses 

£33 such that they are sent to the client 102 in the order the client 102 expects them. These 

^14 ordered responses 126 are stored in a paired message queue 120. The paired message 

=~[15 queue 120 is a data structure which stores the paired messages 1 14 in a FIFO order, 

16 described above. The data structure with appropriate logic may take the form of queues, 

17 linked lists, and the like. 

18 Upon identifying an unpaired message 116, the unpaired message module 110 

19 may create a second data structure similar to the paired message queue 120 which is 

20 called an unpaired message queue 122. The unpaired message queue 122, like the paired 

21 message queue 120, stores the messages in FIFO order. Once impaired messages 116 and 
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1 paired messages 1 14 are stored in the message queues, they are managed by the response 

2 module 112. 

3 The response module 112 communicates responses, both paired 126 and 

4 unpaired 128 to the appropriate client. For each response 126/128 there is an identifier to 

5 indicate to the client 102 which is to receive the response 126/128. During normal 

6 operation, the response module 112 takes the paired message 114 which was stored first 

7 and sends it to the appropriate client 102. If there are unpaired messages 1 16 stored in 

8 the unpaired message queue 122 for this particular client 102, then the response module 
. 3t 9 112 will modify an unpaired messages waiting indicator (not shown) in all paired 

ijio messages sent to the client 102. The unpaired messages waiting indicator allows the 

Q\ 1 client 102 to identify when the server 104 has impaired messages 1 16 for the client 1 02. 

:* 12 If the response module 112 receives an unpaired message control request 118 from the 

C%2 request module 1 06 to send one or more unpaired messages 1 16 to a particular client 102, 

i 3 I 

^J4 then the response module 1 12 will meet the unpaired message control request 118 before 

;^jj5 sending more paired messages 1 14 to the particular client 102. 

16 In order to understand the features and advantages of the present invention, three 

17 scenarios are presented all in reference to Figure 1. First, normal operation is illustrated 

18 by the communication between client 1 (102) and the server 104. Client 1, after 

19 establishing a communications connection with the server 104, sends a request 124 to the 

20 server 104. The request is simply a general database request such as "What is the first 

21 name of the person in the name table of the database?" The request module 106 receives 

22 the request 124 and recognizes it as a normal request. The request 124 is sent to the 
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1 response generator 108. The response generator 108 retrieves from the database 109 the 

2 desired information and packages the data in a response 119. The response 1 19 is then 

3 sent to the unpaired message module 110 which detects that sending this response 1 19 as 

4 the next message to client 1 will be expected by client 1 . Therefore, the unpaired 

5 message module 110 identifies the message as a paired message 114 and stores it in the 

6 paired message queue 120 within the response module 112. The response module 1 12 

7 then communicates the paired message response 1 14 to client 1 (102) by way of paired 

8 message response path 126. Client 1 then receives the paired message response 1 14 and 

_ 9 continues its normal operation. 

*. ft 

□JO In the second scenario, mismatched request 124 and response 126/128 messages 

Ci 

Oil are illustrated in Figure 1. Here, client 1 (102) sends a request 124 to the server 104 just 

as described in the first scenario. However, the request 124 indicates that client 2 is to 

r}3 receive the response 119. The steps within the server 104 until the response 119 enters 

[: ;14 the unpaired message module 1 10 are the same as before. When the unpaired message 

IS s 

Q5 module 110 reviews the response 1 19 the unpaired message module 110 recognizes the 

16 response 1 19 as an impaired message 116. This is an unpaired message 116 because 

17 subsequent to client l's (102) request, but prior to sending client l's (102) response 119 

18 to client 2 (102), client 2 (102) has requested a service of the server 104. Therefore, 

19 sending the response 119 generated by the request from client 1 (102) to client 2 (102) 

20 prior to the response 1 1 9 for client 2 (1 02) generated by the request from client 2 (1 02) 

21 causes client 2 (102) to receive an unexpected response 119. Client 2 is expecting a 
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1 response 1 19 to client 2's (102) request 124. The response to client 2 (102) generated by 

2 the request from client 1 (102) is an unpaired message 116. 

3 The impaired message module 1 1 0 recognizes there is no unpaired message 

4 queue 122 in the response module 1 12. The unpaired message module 1 10 creates a new 

5 unpaired message queue 122. The unpaired message module 1 10 then stores the impaired 

6 message 1 16 in the unpaired message queue 122. Later, the unpaired message module 

7 110 receives from the response generator 108 the response 119 which matches the request 

8 from client 2 (102). This response 1 1 9 is a paired message 114 and is stored in the paired 

9 message queue 120. Because an unpaired message 116 exists in the unpaired message 
;5to queue 122, the response module 112 sets an unpaired messages waiting indicator in each 

94 1 paired message 114 sent to client 2 (1 02). This allows client 2 (1 02) to recognize there 

? = 

are unpaired messages 116 waiting on the server 104. When no unpaired messages 116 

CM3 exist, the unpaired messages waiting indicator is not set. 

J 4 Next, client 2 (102) may decide to request one or more of the unpaired messages 

I* J5 116. Client 2 (102) sends an unpaired message request to the server 104. The request 

16 module 106, then sends an unpaired message control request 1 18 to the response module 

17 1 12. The response module 1 12 responds by sending the requested number of unpaired 

18 messages 1 16 in the unpaired message queue 122 to client 2 (102). Communication of 

19 the unpaired messages 1 16 is illustrated by the dashed lines 128 between the unpaired 

20 message queue 122 and client 2 (102) and client 3 (102). Once the requested number of 

21 unpaired messages 1 16 are sent or the unpaired message queue 122 is empty, the response 

22 module 112 resumes sending paired messages 1 14 to client 2 (102). If the impaired 
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1 message queue 122 is empty then the response module 112 destroys the unpaired message 

2 data structure so use of computing resources on the server 104 is maximized. 

3 In the third scenario, a client 102 may issue a request 124 to the server 104 and 

4 become disconnected and then issue a different request 124 to the server 104. In this 

5 case, client 3 (102) issues a request 124 to the server 104. Processing of the request 

6 continues as normal. While the response generator 108 works on the response, client 3 

7 (102) loses its connection with the server 104. This is illustrated by the dashed line 

8 forming the box around client 3 (102). Loss of connection may occur for various reasons 
^ 9 including severing of the network line between the client 3 (102) and the server 104, or 

a S. 

Q%0 termination of the connection by a user operating client 3 (102). After losing the 

.Sis. 

81 1 connection, client 3 (102) re-connects to the server 104. Then, client 3 (102) makes a 

Z\2 new request 124 which is different from the last. Delivery of the response 1 19 to the 

Cl3 previous request 124 may confuse client 3 (102) or mislead the user. 
^14 The unpaired message module 110 recognizes this and identifies the response 

fl5 1 19 to the previous request 124 as an unpaired message 116. Storage and notification by 

16 the response module 112 then occurs as in scenario 2. A request 124 from client 3 (102) 

17 and fulfillment of the request 124 for these unpaired messages 116 occurs in the third 

18 scenario in the same way as in the second scenario. The difference is the unpaired 

19 message 1 16 was created due to a client 3 (102) request 124, rather than another client's 

20 request. 

21 Figure 2 illustrates the initial connection process 200 of the present invention. In 

22 a client/server model the client 102 generally initiates the communications. In figure 2, at 
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1 step START both the client 1 02 and the server 104 are executing normally on one or 

2 more computers. The client 102 has initiated communications. 

3 In step 202, the client 102 and the server 104 establish their communications 

4 connection. Communications between a client 102 and a server 104 are carried out once 

5 the two systems have agreed upon a communication protocol and have agreed to accept 

6 and send data to each other. Establishment of communications between servers 104 and 

7 clients 102 is well known in the art. 

8 Next, in step 204, the client 102 may request that the server 104 use unpaired 
^. 9 message tracking to ensure the client 102 has access to all server responses 126/128. 
ijto Alternatively, unpaired message tracking maybe available to all clients 102, at all times. 
Sil If the client 102 requests use of unpaired message tracking, then the server 104 would 
•^12 configure itself to provide unpaired message tracking to the client 102. This is done by 
CI3 setting server side program variables such that software implementing the present 

^14 invention will be utilized. If no request is made, then the server 104 would respond to 

,i i 

Q5 client 102 requests in a conventional manner. Also, if no request is made, the process 

16 proceeds to step 210. 

17 In step 210, the server 104 has completed initial preparations to communicate 

18 with the particular client 102. The client 102 is connected. The server 104 now waits for 

19 any requests 124 from this or any other connected client 102. Following step 210 is the 

20 END step. This step illustrates that the establishment of communications step with a 

21 particular client 102 is completed. The server 104 then operates as normal, servicing new 

22 requests and accepting new client connections. 
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1 If the client 102 requests use of unpaired message tracking, then the process 

2 continues to step 206. In this step, the server 104 uses the response module to 1 12 to 

3 determine whether there are unpaired messages 1 16 in the unpaired message queue 122. 

4 If so, then the process continues to step 208. If there are no unpaired messages 116, then 

5 the process proceeds to step 210, discussed above. 

6 In step 208, the server 104 toggles an unpaired messages waiting indicator in 

7 each paired message 1 14 for this client. When these paired messages 1 14 are sent to the 

8 client 102, the client 102 is able to identify there are unpaired messages 116 waiting on 
^ 9 the server 104. The indicator allows the client 102 to determine whether to request 

'-I I 

ntO unpaired messages 116 from the server 104. Following the toggling of the unpaired 
messages waiting indicator, the process proceeds to step 210. 

ft : 

L:*|2 Figure 3 illustrates in flow chart form how the process of the present invention 

ii 

r 13 operates. One advantage of the present invention is that all changes to the normal process 

^14 of client/server transactions are made to the server 104. Therefore, Figure 3 illustrates the 

r\s process steps from the perspective of the server 104. Note that Figure 3 illustrates no 

16 START or END step. Although the server would need to be started and stopped in its 

17 execution on a computer, Figure 3 illustrates the process of the present invention at the 

18 point at which the server 104 has been started and is prepared to receive client requests 

19 124. This is the request handling process 300. 

20 The request handling process 300 is a cycle and ends only when there is a 

21 software or hardware failure in the server 104 or the server 104 is shutdown by a user. 

22 For purposes of discussion, the process begins in step 302. 
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1 Part of step 302 is the server 104 waiting for a request 124 from a client 102. 

2 Waiting for a request requires that the communications connection process of Figure 2 be 

3 completed. When a client request 124 is received by the server 104, the process moves to 

4 step 304. 

5 In step 304, the server 104 determines whether the client request 124 is a request 

6 to receive impaired messages 1 16 or a general services request of the server 104. If the 

7 request 124 is a general services request, then the process moves to step 308. If the 

8 request is for unpaired messages then the process moves to step 306. 

_ 9 A request for unpaired messages may be of several types. The request may be 

□10 that all unpaired messages 1 16 in the unpaired message queue 122 automatically be sent 

CI 

j 31l to the client 102. Alternatively, the client 102 may request a single unpaired message 116 

vJ2 be sent. Alternatively, the client 102 may request that the first unpaired message 1 16 be 

£13 sent and that all subsequent unpaired messages 1 16 be automatically sent to the client 

! ^ J4 102. The server 104 is configured to send unpaired messages 116 to the client in 

;.*J5 accordance with the particular type of request made. 

16 In step 306, depending on the type of unpaired message request, the response 

17 module 1 12 sends one or more of the unpaired messages 1 16 to the client 1 02 from the 

18 unpaired message queue 122. Following step 306, the server 104 has completed the 

19 desired request. Therefore, the process returns to step 302 where the server 104 waits for 

20 the next request from this or any other connected client 1 02. 

21 In step 308, the server 104 has not received a request for impaired messages 1 16. 

22 This means the request is a normal service request 124. To service this request 124, the 
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1 server 104 uses the response generator 108 discussed above. The flow of the response 

2 119 follows the process discussed in relation to Figure 1 . 

3 Step 310 illustrates the determination step which the unpaired messages module 

4 1 10 of the server 104 must make. Logic for determining whether the response 1 19 is 

5 paired or unpaired resides mainly in the unpaired message module 110. If the message is 

6 a paired message, then the process moves to step 312. If the message is an unpaired 

7 message, then the process goes to step 314. 

8 In step 312, the paired message 1 14 is stored in the paired message queue 120. 

_ 9 This step includes delivery of paired messages 1 14 to the client 102. Messages for the 

i) 

00 client 102 may accumulate in the paired message queue 120 or the unpaired message 

j 3l 1 queue 122 because the server 104 must alternate time using the CPU of the computer 

£12 between the plurality of tasks which the server 104 must perform. Because work by the 
server 104 takes time, messages may accumulate in either queue. The message queues 

5 : 

^14 120 and 122 accommodate this accumulation. Following step 312, the server 104 has 

j*|5 completed the desired request. Therefore, the process returns to step 302 where the 

16 server 104 waits for the next request from this or any other connected client 102. 

17 In step 310, if the response 119 is an impaired message 116, step 314 follows. In 

18 step 314, the process determines whether a data structure for storing the unpaired 

19 messages 1 16 exists. If not, then a data structure is configured to store unpaired messages 

20 1 16 in the appropriate order. This data structure is referenced as an unpaired message 

21 queue 122. In alternative embodiments of the present invention, the unpaired message 

22 queues 122 and/or paired message queues 120 may relate to each individually connected 
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1 client 102. Alternatively, the message queues 120 and/or 122 may store and service 

2 messages for all connected clients 102. Steps 316 and 314 both then lead to step 318, 

3 where the unpaired message 1 1 6 is stored in the unpaired message queue 122. 

4 Following step 3 1 8 the server 1 04 has completed the desired process. Therefore, 

5 the process returns to step 302 where the server 104 waits for the next request from this 

6 or any other connected client 102. The result is a process which ensures that all 

7 connected clients 102 may receive both paired messages 114 and unpaired messages 116 

8 intended for the client 102. 

9 A primary advantage of the present invention is that none of the clients 102 

■a? 

;== jo which now exist or will exist need to change their configurations. The present invention 

4«i l allows clients 102 which want to use this process implement some simple logic to request 

Z\l that the server 104 use the process and simple logic for handling the existence of unpaired 

Cl3 messages 1 16 on the server 104. The decision to use the present invention may lie with 

■*}4 the client 102 rather than the server 104. The present invention allows clients 102 which 

Cl5 have logic to handle lost connections and unpaired messages 116 to continue to use the 

16 server's 104 services. Such clients 102 would not experience delays in receiving a 

17 response which use of the process of the present invention would present. The present 

18 invention allows very 'thin' or small clients 102 which operate more easily on portable 

19 computing devices to use the process of the present invention. Additionally, the present 

20 invention may utilize some of the same resources of the server 104 to manage the 

21 identification, storage, and delivery of the unpaired messages 116 which are currently 

22 used to manage paired messages 114, 
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1 The present invention may be embodied in other specific forms without departing 

2 from its spirit or essential characteristics. The described embodiments are to be 

3 considered in all respects only as illustrative and not restrictive. The scope of the 

4 invention is, therefore, indicated by the appended claims rather than by the foregoing 

5 description. All changes which come within the meaning and range of equivalency of the 

6 claims are to be embraced within their scope. 

7 What is claimed and desired to be secured by United States Letters Patent is: 



CI 
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